This application relates generally to communication networks, and more particularly, to a method and system for retaining learned routes in the event of a routing protocol connectivity failure between intermediate routers in a communication network.
Computer network data communication involves the exchange of data between two or more entities interconnected by communication links and sub-networks. Routers interconnect the communication links and subnets to enable transmission of data between end nodes. Communication software executing on routers correlates and manages data communication with other routers. The routers typically communicate by exchanging discrete messages or packets of data according to predefined protocols, such as the Transmission Control Protocol/Internet Protocol (“TCP/IP”). A protocol consists of a set of rules defining how the routers interact with each other. In addition, network routing software executing on the intermediate routers allows expansion of communication to other nodes. Collectively, these hardware and software components comprise a collection of communication networks.
Since management of data communication networks can prove burdensome, smaller groups of one or more computer networks can be maintained as separate routing domains or autonomous systems (“AS”). An AS is a network or group of networks under a shared technical administration and with common routing policies. An Internet Service Provider (“ISP”) is an example of an AS that interconnects dispersed networks to provide Internet connectivity.
Interior Gateway Protocols (“IGPs”), such as conventional link-state protocols, are intra-domain routing protocols that define the manner with which routing information and network-topology information are exchanged and processed within a particular AS. Examples of conventional link-state protocols include, but are not limited to, the Open Shortest Path First (“OSPF”) protocol and the Intermediate-System-to-Intermediate-System (“ISIS”) protocol.
A plurality of interconnected AS domains may be configured to exchange messages in accordance with an inter-domain routing protocol, such as the Border Gateway Protocol (“BGP”). BGP allows each AS to independently create its own routing policies to override distance metrics when appropriate. To address this flexibility, BGP advertises routes for carrying data to the address space indicated by the IP prefix of the announced route. When a BGP router advertises to a neighbor that it has a path for reaching a specific IP prefix, the neighbor has a high degree of confidence that the advertising BGP router will actively use the specific path to reach the target destination. The popularity of BGP is due, in part, to its ability to distribute reachability information selecting the best route to each destination according to policies specified for each AS.
To implement the BGP protocol, each routing domain can include at least one provider edge (“PE”) router that advertises routes to a PE router of another AS. Before transmitting such messages, however, the PE routers cooperate to establish a logical “peer” connection or session. These PE routers are also known as “originators” or “BGP speakers.” Two BGP speakers with an open BGP session for the purpose of exchanging routing information are referred to as “peers” or “neighbors.” BGP typically performs routing between AS domains by exchanging routing information among BGP speakers of each AS. BGP speakers also send update messages whenever a change in the topology occurs. For example, if a route is no longer accessible for any reason, a withdrawal of that route is propagated among the peers, which can delete a route from a router's control plane. BGP relies on pre-existing connectivity provided by IGP routes.
Two BGP enabled PE routers not in the same AS can use external BGP (“eBGP”) to exchange routes. The routing information exchanged by eBGP neighbors typically includes the address of a PE router in another AS, which is also known as the “next hop” address. When a BGP speaker receives updates from multiple AS domains describing different paths to the same destination, the speaker typically chooses a single best path for reaching that destination. Once chosen, the speaker can use internal BGP (“iBGP”) to propagate that best path to its AS neighbors, including the “next hop” associated with that best path. Each route advertised by BGP must have a “next hop” address that is reachable through IGP in order for that route to be considered valid. iBGP speakers within an AS are typically required to connect in full mesh to ensure that all iBGP speakers receive route updates from other iBGP speakers. However, the full mesh requirement can become very burdensome in more complex topologies.
Existing networks have alleviated this limitation by the use of advertisers or route reflectors (“RR”), which are special routers acting as a focal point for iBGP sessions. Multiple iBGP speakers can establish an iBGP peer with one RR, rather than establish an iBGP peering session with every other node in full mesh. The RR can take responsibility of re-advertising or “reflecting” learned routes from another BGP speaker within an AS.
In existing systems, the current implementation of BGP treats an originator and advertiser (“RR”) of a route equally in the event that there is a loss of BGP connectivity between routers. Such existing systems using the current implementation of BGP will withdraw all routes toward a particular “next hop” when there is a BGP connectivity failure between BGP speakers or an iBGP connectivity failure between an advertiser and one of its peers within an AS, regardless of whether the “next hop” is still accessible via IGP.
One approach to mitigating the effects of a BGP session failure is a BGP extension known as graceful restart, which drops control plane connections to its routing peers for a short time, during which traffic forwarding continues, and restarts the control plane with a new instance of the routing tables. For graceful restart to be successful, all peers must have compatible graceful restart extensions that are negotiated during start up. This compatibility requirement becomes problematic in more complex topologies. Furthermore, graceful restart unnecessarily drops the control plane connection when an intermediate advertiser or RR fails, but the route originator is still accessible via IGP.
Thus, it is desirable to have a local solution requiring no extension compatibility between peers that can differentiate between the failure of an originator and an advertiser. Such a solution would retain routes learned from an intermediate advertiser or RR if the originator is still reachable via IGP, notwithstanding its BGP session termination.